home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Turnbull China Bikeride
/
Turnbull China Bikeride - Disc 2.iso
/
STUTTGART
/
GRAPHICS
/
RAYTRACING
/
POVRAY-2.2
/
POVFRONT
/
ReadMe
Wrap
Text File
|
1994-07-07
|
5KB
|
76 lines
POVray2 Setup Version 1.12 - July 1994
==========================
This fixes a couple of 'anomalous features' (read bugs) which were present
in Version 1.11 (the first release version). These are:
1.) In version 1.11, an error 'Bad filename .xxx at code 7670' was produced
if you deselected the save box option, and specified a system variable which
hadn't been defined in the 'Path' submenu. Since I supplied the program with
the default path set to <POVpicture$Dir> (which was defined during the boot
up sequence on my machine - see below), this error will almost certainly
have been produced if you tried to use version 1.11 in non-save-box mode
without first setting the path to something sensible (Using 'Save defaults'
from the icon bar menu will save your choice of destination path name).
Version 1.12 now checks the destination path name when 'Start' is clicked,
and will produce a warning if it is in non-save-box mode and the destination
path name is undefined/invalid (error 'Invalid desination path name' is
reported. This reflects the problem better than the rather enigmatic error
above). Also, non-existent destination directories are detected, and this is
also reported. Thanks to everyone who brought this one to my attention!
2.) Whilst fixing the above, I noticed the rather inconsistent behaviour of
the Path submenu itself. In version 1.11, if you had 'Use save box'
selected, then entered text into the path submenu, the 'Use save box' option
would be deselected, and the 'Path' menu item would be ticked. This is as
expected. If, however, you then changed the text in the submenu, the 'Path'
menu item would be deselected (i.e. its status was toggled). This obviously
should not happen, and has been fixed in version 1.12 (i.e. the 'Path' item
now remains selected when the text is changed, until you actually click on
the 'Path' item itself, or select 'Use save box'. This is what should have
happened originally.
3.) Version 1.11 had a rather restrictive limit on the maximum length of the
path and library names. This has now been increased.
The !!Scenes directory
======================
As I mentioned above, the <POVpicture$Dir> system variable was always set on
my machine. This was done by the !!Scenes directory, which exists solely to
do this, and also to set up the #include library directory (note: it
expects the #include files to be in a directory called 'inc' which itself
is in the same directory as the !!Scenes application, i.e. 'inc' should be
in the same filer window as !!Scenes), and provide somewhere to store the
output scene files (obviously!). Since this was always present in my
machine, I didn't notice problem number 1 above until told about it! I had
meant to include !!Scenes in the first release (1.11), but I forgot....
Anyway, it's here now. It is, of course, completely independent of the POV
front end, which is in no way reliant upon it (other than to set up the
system variables, if you use them), and it's up to you if you want to use it
or not.
Incidentally, just as an aside, I have not yet been able to test the
'Library' option in the menu, because I've not been able to get hold of an
executable which actually works properly - those which I've tried (one is
2.0, the other 2.2, both of which I got from HENSA) both have bugs which
mean that the library option parameter fails. The POV front end apparently
passes the library parameter specified in the sub-menu correctly, but the
executable messes up (it does this when run from the command line, too).
Also, with the 2.0 executable (which I normally use - it seems a little less
kludged than version 2.2, which seems to interpret the #include line in a
rather odd way, which although it makes it easier to port scene description
files from other machines is completely different to what I've used in all
my previous scenes [#include <POVinc$Dir>.colors etc, which I normally use,
does not work with this!]), the continue option does not seem to work. I
don't think this is the fault of the front end, which correctly passes a
'+C' parameter, but I'm willing to be corrected on this if I goofed and
should have had another parameter as well.
Anyone want to volunteer to produce an executable which works properly (I
would have a go, but I don't know diddly about C - any C gurus out there can
find the sources by Internet ftp to alfred.carleton.ca [I think - mail me if
this doesn't work and I'll look it up properly]. The sources do include
Acorn specific headers and supposedly do compile on the Acorn C compiler...)
Brian Ruth (b.ruth@ucl.ac.uk)